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TFTP Option Extension 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1998). All Rights Reserved. 
Abstract 
The Trivial File Transfer Protocol [1] is a simple, lock-step, file 
transfer protocol which allows a client to get or put a file onto a 
remote host. This document describes a simple extension to TFTP to 
allow option negotiation prior to the file transfer. 


Introduction 


The option negotiation mechanism proposed in this document is a 


backward-compatible extension to the TFTP protocol. It allows file 
transfer options to be negotiated prior to the transfer using a 
mechanism which is consistent with TFTP’s Request Packet format. The 


mechanism is kept simple by enforcing a request-respond-acknowledge 
sequence, similar to the lock-step approach taken by TFTP itself. 


While the option negotiation mechanism is general purpose, in that 
many types of options may be negotiated, it was created to support 
the Blocksize option defined in [2]. Additional options are defined 
in: [3]: 


Packet Formats 
TFTP options are appended to the Read Request and Write Request 
packets. A new type of TFTP packet, the Option Acknowledgment 


(OACK), is used to acknowledge a client’s option negotiation request. 
A new error code, 8, is hereby defined to indicate that a transfer 
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should be terminated due to option negotiation. 


Options are appended to a TFTP Read Request or Write Request packet 
as follows: 


+------- +---7 === +---+---7 "=== +---+---7 "=== +---+---7 ~---+---+--> 
| ope |filename| 0 | mode | 0 | opti | 0 | valuel | 0 | < 
+------- +=" T= - Hf 5-4 TT mr TT mr mn TT ---4--> 
>------- +---+---7 Tot 

< optN | 0 | valuen | 0 | 

>------- +---+---7 Tot 

opc 


The opcode field contains either a 1, for Read Requests, or 2, 
for Write Requests, as defined in [1]. 


filename 
The name of the file to be read or written, as defined in [1]. 
This is a NULL-terminated field. 


mode 
The mode of the file transfer: "netascii", "octet", or "mail", 
as defined in [1]. This is a NULL-terminated field. 

opt1 


The first option, in case-insensitive ASCII (e.g., blksize). 
This is a NULL-terminated field. 


valuel 
The value associated with the first option, in case- 
insensitive ASCII. This is a NULL-terminated field. 


optN, valueN 
The final option/value pair. Each NULL-terminated field is 
specified in case-insensitive ASCII. 


The options and values are all NULL-terminated, in keeping with the 
original request format. If multiple options are to be negotiated, 
they are appended to each other. The order in which options are 
specified is not significant. The maximum size of a request packet 
is 512 octets. 


The OACK packet has the following format: 


Malkin & Harkin Standards Track [Page 2] 


RFC 2347 TFTP Option Extension May 1998 


+------- tee de +—=-+—==" "=== +===+ ===" "=== TT == +—=—-+ 
| ope | opt1 | 0 | valuel | 0 | optn | 0 | valuen | 0 | 
+—====== Gs re å Ft Ut an nd rar rn ad it dd 
ope 


The opcode field contains a 6, for Option Acknowledgment. 


optl 
The first option acknowledgment, copied from the original 
request. 

valuel 
The acknowledged value associated with the first option. If 


and how this value may differ from the original request is 
detailed in the specification for the option. 


optN, valueN 
The final option/value acknowledgment pair. 


Negotiation Protocol 


The client appends options at the end of the Read Request or Write 
request packet, as shown above. Any number of options may be 
specified; however, an option may only be specified once. The order 
of the options is not significant. 


If the server supports option negotiation, and it recognizes one or 
more of the options specified in the request packet, the server may 
respond with an Options Acknowledgment (OACK). Each option the 
server recognizes, and accepts the value for, is included in the 
OACK. Some options may allow alternate values to be proposed, but 
this is an option specific feature. The server must not include in 
the OACK any option which had not been specifically requested by the 
client; that is, only the client may initiate option negotiation. 
Options which the server does not support should be omitted from the 
OACK; they should not cause an ERROR packet to be generated. If the 
value of a supported option is invalid, the specification for that 
option will indicate whether the server should simply omit the option 
from the OACK, respond with an alternate value, or send an ERROR 
packet, with error code 8, to terminate the transfer. 


An option not acknowledged by the server must be ignored by the 
client and server as if it were never requested. If multiple options 
were requested, the client must use those options which were 
acknowledged by the server and must not use those options which were 
not acknowledged by the server. 


Malkin & Harkin Standards Track [Page 3] 


RFC 2347 TFTP Option Extension May 1998 


When the client appends options to the end of a Read Request packet, 
three possible responses may be returned by the server: 


OACK - acknowledge of Read Request and the options; 


DATA - acknowledge of Read Request, but not the options; 
ERROR - the request has been denied. 


When the client appends options to the end of a Write Request packet, 
three possible responses may be returned by the server: 


OACK - acknowledge of Write Request and the options; 
ACK - acknowledge of Write Request, but not the options; 
ERROR - the request has been denied. 


If a server implementation does not support option negotiation, it 
will likely ignore any options appended to the client’s request. In 
this case, the server will return a DATA packet for a Read Request 
and an ACK packet for a Write Request establishing normal TFTP data 
transfer. In the event that a server returns an error for a request 
which carries an option, the client may attempt to repeat the request 
without appending any options. This implementation option would 
handle servers which consider extraneous data in the request packet 
to be erroneous. 


Depending on the original transfer request there are two ways for a 
client to confirm acceptance of a server’s OACK. If the transfer was 
initiated with a Read Request, then an ACK (with the data block 
number set to 0) is sent by the client to confirm the values in the 
server’s OACK packet. If the transfer was initiated with a Write 
Request, then the client begins the transfer with the first DATA 
packet, using the negotiated values. If the client rejects the OACK, 
then it sends an ERROR packet, with error code 8, to the server and 
the transfer is terminated. 


Once a client acknowledges an OACK, with an appropriate non-error 
response, that client has agreed to use only the options and values 
returned by the server. Remember that the server cannot request an 
option; it can only respond to them. If the client receives an OACK 
containing an unrequested option, it should respond with an ERROR 
packet, with error code 8, and terminate the transfer. 
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Examples 


Read Request 


client server 
|1|foofile|O|octet|0|blksize|0|1432/0| --> RRQ 
<-- |6|blksize|0|1432|0| OACK 
Jalo] --> ACK 
<-- |3|1| 1432 octets of data | DATA 
Jaji] --> ACK 
<-- |3|2| 1432 octets of data | DATA 
|4|2| --> ACK 
<-- |3|3|<1432 octets of data | DATA 
[4|3| --> ACK 


Write Request 


client server 
|2|barfile|O|octet|0|blksize|0|2048/0| --> RRQ 
<-- |6|blksize|0|2048|0| OACK 
|3|1| 2048 octets of data | --> DATA 
<-- |4|1| ACK 
|3|2| 2048 octets of data | --> DATA 
<-- |4|2| ACK 
|3|3|<2048 octets of data | --> DATA 
<-- |4|3| ACK 


Security Considerations 
The basic TFTP protocol has no security mechanism. This is why it 
has no rename, delete, or file overwrite capabilities. This document 
does not add any security to TFTP; however, the specified extensions 
do not add any additional security risks. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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